CAT: Component Architecture for Tailorability - Textual syntax and a possible graphical representation

components_list È Abstract_components_list Abstract_component Abstract_component Implemented Components Implemented component types are described by the following productions. The component body consists of a list of provided ports, a list of required ports, and a list of parameter definitions. The provided ports represent services which the component can offer if it is composed with other components. The required ports represent services which the component needs if it is composed with other components. The notion of ports and services is rather abstract. If CAT is used in conjunction with an implemented component model, it has to be mapped to the composition mechanism of the respective component model (e.g. Event-mechanisms in JavaBeans, or Remote Method Invocation in CORBA (see OMG (1995))). Implemented_component È i_component comp_type_name { i_component_body } i_component_body È ports parameters ports È required_list provided_list required_list È required_list required_port required_port Every port has a name and a type. The type represents the composition mechanism which applies to this port (e.g. Push-Event-Source in a hypothetical JavaBeans Button). The name is local to the component. In CAT the port types can be used to check the compositional correctness of the program (i.e. whether all port connections are legal). required_port È required port_name type_name; provided_list È provided_list provided_port provided_port provided_port È provided port_name type_name; The parameters of an implemented component are supposed to map to the properties of the respective component implementation (e.g. as a JavaBean). Therefore, they support the basic Java types. parameters È parameter_list parameter parameter parameter È config_parameter parameter_name javatype; config_parameter parameter_name javatype := javaliteral; Types, Literals, and Names in CAT As mentioned above, due to its current purpose, CAT makes use of the definition of simple types and literals of Java as described in Gosling et al. (1996). However, in order to include the string type (which is in Java not specified as a primitive type, but as a class) we have used a construct naming all used types including strings. For the definition of literals, however, we refer to page 19 in Gosling et al. (1996). All non-terminals ending with _name are IdentifierChars (see p. 17 in Gosling et al. (1996)), but not CAT-keywords (i_component, a_component, s_component, subcomponent, required, provided, config_parameter, bind, boolean, integer, byte, short, int, long, char, float, double, string). javatype È boolean integer byte short int long char float double string javaliteral È Literal (p. 19 in Gosling et al. (1996)) *_name È IdentifierChar (p. 17 in Gosling et al. (1996)) but not CATkeyword Abstract components Abstract components are aggregations of implemented components or other already specified abstract components. Thus, recursive specification of abstract components is not allowed. In addition to the components ports and parameters, the component body contains the specification of subcomponents and bindings. The bindings can be between subcomponents only or between a subcomponent and the abstract component. In former case, only required and provided ports of the same type can be bound. In the latter case required ports can only be bound to required ports, and provided ports only to provided ports. Again the type restriction applies. All ports of subcomponents and all newly defined ports of the abstract component have to be bound. Parameters of subcomponents can either be statically defined within the subcomponent parameter settings body or bound to parameters of the abstract component. As abstract components have no implementation, all parameters of the abstract component have to bound to parameters of subcomponents. Type restriction applies.components Abstract components are aggregations of implemented components or other already specified abstract components. Thus, recursive specification of abstract components is not allowed. In addition to the components ports and parameters, the component body contains the specification of subcomponents and bindings. The bindings can be between subcomponents only or between a subcomponent and the abstract component. In former case, only required and provided ports of the same type can be bound. In the latter case required ports can only be bound to required ports, and provided ports only to provided ports. Again the type restriction applies. All ports of subcomponents and all newly defined ports of the abstract component have to be bound. Parameters of subcomponents can either be statically defined within the subcomponent parameter settings body or bound to parameters of the abstract component. As abstract components have no implementation, all parameters of the abstract component have to bound to parameters of subcomponents. Type restriction applies. Abstract_component È a_component comp_type_name { i_component_body a_component_body }component È a_component comp_type_name { i_component_body a_component_body } a_component_body È subcomponents bindings subcomponents È subcomponents subcomponent subcomponent È subcomponent local_name comp_type { parameter_settings }; subcomponent local_name comp_type; parameter_settings È parameter_settings parameter_setting parameter_setting paramerter_setting È parameter_name := javaliteral; bindings È component_bindings parameter_bindings component_bindings È component_bindings component_binding component_binding È bind local_name . port_name -> local_name . port_name ; bind port_name -> local_name . port_name ; bind local_name . port_name -> port_name ; parameter_bindings È parameter_bindings parameter_binding parameter_binding È bind parameter_name -> local_name . parameter_name ; System component The System component is similar to an abstract component, the difference being that it has no ports of its own. It represent a closed system. The system component can have, however, configuration parameters, which again have to bound to parameters of subcomponents. System_component È s_component comp_type_name { s_component_body } s_component_body È paramters subcomponents bindings Remarks on the textual syntax The grammar presented here is designed for easy understanding and not for use in a compiler. Example The example presented here is drawn from Magee et al. (1995), extended with the notion of configuration parameters. Regard the following CAT-program: i_component low-pass-filter { required in sound_signal; provided out sound_signal; config_parameter border_frequency integer; } i_component high-pass-filter { required in sound_signal; provided out sound_signal; config_parameter border_frequency integer; } a_component band-pass-filter { required in sound_signal; provided out sound_signal; config_parameter upper_border_frequency integer; config_parameter lower_border_frequency integer; subcomponent filter1 low-pass-filter; subcomponent filter2 high-pass-filter; bind filter1.in -> in; bind filter1.out -> filter2.in; bind filter2.out -> out; bind upper_border_frequency -> filter1.border_frequency; bind lower_border_frequency -> filter2.border_frequency; } s_component filter-system { config_parameter frequency integer; subcomponent filter3 band-pass-filter { upper_border_frequency := 1000; }; bind band-pass-filter.lower_border_frequency -> frequency; } The example presented here contains the important elements of the CAT-language. At first, two implemented components are specified. Both have an inand out-port each. The ports are of the type sound-signal, which is not interpreted in CAT, just statically checked within a bind-construct. The components each have one configuration parameter, which allows to customize the filters to a specific lower, resp. upper frequency-border. The abstract component defines a band pass filter, which consists of a pair of serially connected low pass and a high pass filters. The abstract components defines two configuration parameters which are bound to the respective frequencies parameters of the subcomponents. The ports of the abstract component are bound to the in-port of the first filter, resp. the out port of the second filter. The out-port of the first filter is connected to the in-port of the second filter. The system component finally specifies the whole system as consisting of one band pass filter component fixed to a upper frequency of 1000, while the lower frequency is bound to a configuration parameter of the system. The specification of an application using the textual syntax is precise, however not readily understandable. In the following section we will introduce a graphical representation of the language, again building on DARWIN (see Magee et al. (1995)). Graphical representation In this section we describe how a graphical representation of an application is derived from a given textual description. Starting with the system component we evaluate the textual CATprogram backwards. In the following we will use the filter example from the last section. We begin with the system component. All components are represented by rectangular boxes. Parameters are represented by little squares, labeled with parameter name and type. Thus, the system component in the example is presented in figure 1: Figure 1: Graphical representation of system component in the example Subcomponents are completely within the area of the respective abstract (or, on the top-level, system) component and do not touch the border of the enclosing component. Ports are represented by circles on the border of the respective component. Required ports are empty (‰), provided port are filled (l). Ports are labeled with port name and type. Parameter bindings are represented by lines connecting the respective parameter representations (squares). Thus, from the system component we go backwards to the last (and, in the example, only) abstract component, as shown in figure 2: Figure 2: Graphical representation of abstract component and parameter binding The abstract component in the example consists of two implemented subcomponents which are represented using the same conventions as above. Port bindings are represented by lines connecting the respective port representations (circles). After evaluating the two subcomponents we are finished and the graphical representation of the abstract component is shown in figure 3 (Figure 3 does not show the complete representation, only the "internals" of filter3 in figure 2.): Figure 3: Graphical representation of abstract component with port bindingsThe graphical representation is designed to quickly present parts of an application. It would berather cumbersome to fully display a complex application with several abstraction levels in onerepresentation. Bibliography[1] Gosling, J., Joy, B., and Steele, G., The Java Language Specification. Reading, Mass.:Addision-Wesley, 1996.[2] Hopcroft, J. E. and Ullman, J. D., Introduction to Automata Theory, Languages, andComputation. Reading, Mass.: Addison-Wesley, 1979.[3] JavaSoft, “JavaBeans 1.0 API Specification,” . Mountain View, California: SUNMicrosystems, 1997.[4] Magee, J., Dulay, N., Eisenbach, S., and Kramer, J., “Specifying Distributed SoftwareArchitectures,” in: Proceedings of 5th European Software Engineering Conference,Barcelona, 1995.[5] OMG, “The Common Object Request Broker: Architecture and Specification,” , 2.0 ed:Object Management Group, 1995.